The development of the Internet, and in particular the development of the World Wide Web (“WWW”), has created a mechanism whereby a tremendous amount of information has been made publicly available to anyone who has access to a client computer. For example, by interacting with a client computer, a user can connect to thousands, if not millions of different web sites to access and/or retrieve information that is contained within an electronic document or web page.
To provide access to their web site, many businesses contract with an Internet Service Provider (“ISP”) to host the company's web site. For many companies, there is a strong desire to obtain statistical information regarding the traffic or “hits” on the company's web site. Thus, as part of hosting a company's web site, an ISP will typically collect a variety of statistical information about each of the hosted web sites. For example, an ISP may collect statistical information such as, the number of access requests (“hits”) that are received for a particular site, the volume of hits that are received by a web site during any particular time of day, the frequency that a certain page or image is accessed within the web site, along with other statistical information that may be deemed important for a particular web site.
Traditionally, an ISP will typically assign a single web site domain to each web server. By assigning a single web site domain to each web server, the ISP can easily monitor and log statistical information about the activity that is associated with the web site domain. For example, FIG. 1A illustrates a system 100 in which a web server (SITE_A.COM WEB SERVER 102) has been configured to host a single web site domain (“SITE_A.COM”). In this example, multiple server threads (SITE_A server threads 110, 112, 114, 116), executing in a memory address space 108, service requests for access to the single web site domain SITE_A.COM. In addition, in order to monitor the activity that is associated with the SITE_A.COM domain, as part of servicing the requests from client devices (130, 132, 134, 136), SITE_A server threads 110, 112, 114, 116, repeatedly write SITE_A access information into buffers 120, 122, 124, 126. Thereafter, because each of the buffers 120, 122, 124, 126, are guaranteed to only contain access information for the single web site domain (SITE_A.COM), if any of the buffers 120, 122, 124, 126 become full, the contents of the buffer may be stored to a single file (for example, siteA.com log file 106 on physical disk 104), without having to determine which web site domain was associated with the request. Thereafter, statistical information may be later generated for SITE_A.COM domain based on the access information that was stored to physical disk 104.
However, while the practice of assigning a single web site domain to a web server can significantly reduce the complexity of generating and logging statistical access information for a particular web site domain, the practice also introduces a significant scalability problem. For example, using the described configuration, for an ISP to be able to host a hundred different web site domains, the ISP would need to purchase and maintain a hundred different web servers. For most ISPs, maintaining a one-to-one relationship between the number of web servers and the number of web site domains that the ISP can support is both inefficient and financially impracticable.
In an attempt to address the scalability problem, some web servers have been configured to include multiple server threads that execute within separate processes within their own individual memory space. By executing multiple server threads as separate processes within their own individual memory space, certain complexities that are typically associated with generating and logging statistical access information for multiple web site domains may potentially be reduced.
For example, FIG. 1B illustrates a system 150 that includes a web server 152 that consists of multiple server threads (160, 162, 164, 166) each of which execute in a separate memory space 158a–d, respectively. In addition, server threads 160, 162, 164, 164, are respectively associated with buffers 170, 172, 174 and 176, which are each used to buffer access information for a distinct web site domain (SITE_A.COM, SITE_B.COM, SITE_C.COM, SITE_D.COM), and to store the information to disk 154 within a corresponding log file 156a–d. By servicing multiple web sites in a single web server, certain inefficiencies that are associated with the system 100 depicted in FIG. 1A can be reduced. In addition, because each server thread (160, 162, 164, 166) executes in a separate memory address space and services access requests for only a single web site domain, the problem of ensuring that log data for one site is not incorrectly stored in the physical log file of another can generally be reduced.
However, a significant drawback with the configuration of system 150 is that by requiring specific processes to be used to service specific web site domains, a scalability problem is again introduced in the system. For example, if SITE_A and SITE_B receive heavy traffic while SITE_C and SITE_D typically receive little or no traffic, up to fifty percent (50%) of system 150 resources (e.g., server threads, buffers, etc.) may sit idle and thus be wasted. In addition, system 150 requires that each web site domain be associated with its own process, which in the case of multiple web site domains can cause the system resources to quickly become depleted. Still further, the overhead that is associated with swapping between the different memory address spaces for each of the server threads can itself be a significant drain on the system resources.
Based on the foregoing, there is a clear need for an improved mechanism that allows multiple web site domains to be efficiently serviced by a single web server.